Macademic for Students & Teachers

home *** CD-ROM | disk | FTP | other *** search

/ Macademic for Students & Teachers / Macademic for Students and Teachers (Quantum Leap)(1992).iso / Fun & Games / AdventureMaker / AdventureMaker Docs.txt < prev next >

Wrap

Text File | 1988-09-23 | 61.4 KB | 1,210 lines | [TEXT/QED1]

Welcome to AdventureMaker Version 1.0 Copyright 1988, Paticia B. Smith AdventureMaker is free for your own pleasure and use. However, if you create an adventure that you are particularly proud of and wish to distribute publically, then you must pay the registration fee for AdventureMaker which is $30. AdventureMaker is copyrighted, and I reserve all rights to it. Please do not remove this notice. Thanks. Patricia Smith Epiboly SoftWare CIS: 70655,425 325 E. 79th Street, Apt. 13d MacNet: SmithPB New York, NY 10021 Genie: P-Smith INTRODUCTION AdventureMaker is an AdventureFile generator. It enables you to write text adventures that can then be played with the desk accessory Adventure! Writing an adventure can be a rather involved project. You need to structure a plot of some kind. Then create a map of 'rooms', i.e. the locations in which your story takes place. The rooms must then be tied together with objects and actions that direct the player through your story and ultimately to some kind of solution or victory. Writing an adventure is not easy. I have tried to make it "convenient" with AdventureMaker, but it's still not easy. Before you begin I urge you to read these instructions through thoroughly. Learning to use AdventureMaker is a little bit like learning a programming language. You have to learn some of the commands and syntax of the language before you can do much of anything with it. And what can you do with it? My first AdventureFile was a very traditional adventure. I like the old colossal cave, magic and mazes, so that's what I wrote. But everyone is different, and this is your chance to write the adventure you always wanted to see. Here are some ideas for possible adventures: - A historical adventure. This could be a learning experience for the player as well as being fun and exciting. How about Napoleon's march into Russia from the perspective of one of the foot soldiers? Or the Gold Rush of 1849? How about great tales of exploration, Magellan's voyage around the world for example. - Adventures are a wonderful learning environment for children. They learn reading, verbs and nouns, spelling, typing, and (hopefully) logical thinking. Create an adventure for your children. Perhaps you can use one of their favorite stories. Or better yet, have the adventure be about your child! - Try writing a "simulation", like running a small country or an entire planet. Or building a small company into a corporation. How about a sailing simulation, cruising unknown small islands through coral reefs and hurricanes. - The adventure format lends itself nicely to murder mysteries. You know you've always wanted to write one, so do it. - An adventure is always a series a small puzzles. But why not try writing one big puzzle, a crossword puzzle for example. What fun! Each room could be a letter or word in the grid. - These are all suggestions for standard adventures. But you can use the Adventure! desk accessory for other things as well. Set up an interactive tour of your company. Use the Adventure! DA for an interactive help file or tutorial. Teachers could write history lessons in adventure format, or reading exercises or logic experiments. If anyone wants to pursue this, I would be glad to modify some of the internal responses in the program to meet your needs. Let your creative juices flow. Relax all your inhibitions. Be sneaky, crafty, wily and obtuse. Stick in all your favorite brain teasers. Travel through your dreams. Writing an adventure is the most exciting adventure of all. Good Luck! OVERVIEW: HOW ADVENTURE! WORKS Adventure! has a very simple structure. There are Rooms, within which there are Objects upon which Actions can be performed. These three parameters - Rooms, Objects, Actions - determine everything that happens and can happen in Adventure! Each parameter has its own type of data record (RoomRecords, ObjectRecords, and ActionRecords) and all of the records are linked. Rooms call objects, objects call actions, actions call objects, objects call rooms. The hard part in writing an adventure is making sure that you have all the links right. There is a fourth very important parameter in Adventure! and that is called a Block. In order to minimize disk access while conserving memory, Adventure! groups sets of Rooms, Objects, and Actions together in Blocks. Each block contains up to 10 rooms, up to 15 Actions and up to 20 Objects. An entire block (all of the Room, Object, and Action data) is loaded into memory at one time. As long as the player stays inside a block, there is no further disk access. When the player leaves a block and travels to a new one, Adventure! goes to its AdventureFile and loads in an entirely new block, i.e. a new set of Rooms, Objects, and Actions. Adventure! can have up to 10 blocks, which means your adventure can have 100 Rooms, 200 objects and 150 actions. You'll find that you can actually have quite a few more objects and actions than this because Adventure! allows six different 'names' for each object and for each action. This represents an extremely large vocabulary, 3000 words in all. This large of a vocabulary, along with the descriptions for each room and object, and the responses for each action, represents a _lot_ of data, roughly 350K on disk. This is simply too much baggage for a desk accessory to carry around with it. So AdventureMaker "crunches" or compresses the data when it creates an AdventureFile. This compressed disk file is called a Crunch File. While you are developing an adventure however, you will be working exclusively with another type of disk file: a Block File. Block Files are non-compressed data sets. They are called Block Files because their internal structure is the same as the 'blocks' referred to above. A single block in a Block File is always the same size, 35K, even if the block is completely empty. Crunch Files, on the other hand, are the compressed final product that the Adventure! desk accessory can read. The crunching process removes all empty records and blanks, so a sparse block, once crunched, is quite small, while a full block, in the limit, approaches 35K. Block Files can be revised non-sequentially; Crunch files cannot be revised once written. Crunch Files are not just compressed block data. They also include important header information, including, among other things, the title and author of the adventure, sounds for dying and winning, and a set of hints. You can modify all of this information in AdventureMaker. When you are satisfied with it, save it to disk as a Header File. Before you crunch a Block File, read in the header information you have prepared. The header will be crunched first, then the rest of your crunched Block File appended to this. A Crunch File _is_ an AdventureFile. It is ready to be run by the Adventure! desk accessory. All you need to do to run it is to name it "AdventureFile" and put it in your System Folder. You could, alternatively, save the Crunch File directly to your System Folder as "AdventureFile" rather than renaming it and moving it there. This is a little dangerous however, because you don't want to inadvertently overwrite an existing AdventureFile. GETTING STARTED When you first open AdventureMaker, you will be presented with AdventureMaker's main screen. This is the control center of the program. From here, you can read blocks from disk Block Files, you can create and modify Room, Object, and Action records, and you can modify header information. Also, you can get a Summary of the current block that you are working on. When you are finished, you can save the block to disk as a new Block File or you can write it to an existing Block File. Finally, after you have created a set of blocks, you will want to crunch them to a Crunch File. You do all your work in AdventureMaker on a block in memory. This is referred to as the current memory block. When you are satisfied with your changes and additions to the memory block, write the block to disk as a Block File or your work will be lost. Note that Crunch Files _cannot_ be read by AdventureMaker. So if you save your work as a Crunch File only, you won't be able to retrieve it. (There are cautionary Alerts all over the place in AdventureMaker. Reminding you to save your work is one of them. If you get tired of all that nagging, you can turn the alerts off by checking the "No Alerts" check box. Don't do this if you are at all forgetful. I always leave it unchecked myself.) The "Input/Output Block Number": The numbering of blocks in a Block or Crunch File is very important. The numbers have two functions: First, they indicate the actual physical order of blocks in the disk files. Second, the block numbers are the tags by which Adventure! moves around and calls up new data. When you first start AdventureMaker, you will be working on Block 1 (unless you have read in a block from a larger existing file). When you have finished working on this block, you will want to write it to disk as a Block File. Type '1' in the Block Number box, then click the "Create New BlockFile" button. Since this will be the first block in the new Block File, it _must_ be numbered '1'. Block Files must be built sequentially. If you tried to write this block to a new file as Block 3 or Block 8, AdventureMaker wouldn't let you. When you have finished with Block 1, you will want to start on Block 2 of your adventure. Click the "New Empty Block" button to zero out all of the Room, Object and Action Records, then fill in the records for the new block. When you are done, you may either save the block to your existing Block File as block#2 (it will be, physically, the second block in the file) or you may want to save it by itself in its own Block File. If you do this, be sure to give the file a distinctive name, like "Block 2". However, since this block will be, physically, the first block in the file named "Block 2", you must save is as block #1. Later, you can combine all of your separate single-block files into one big Block File with sequentially numbered blocks. When you do this, your Block 2 will need to be, physically, the second block in the large combined file. It will be saved to the big Block File at that time as block#2. When you have finished with a series of blocks, you will want to "crunch" them, i.e. turn them into an AdventureFile, so that you can try out your new adventure with the Adventure! desk accessory. Before you do this, however, you must write the header information for your Adventurefile. Header Information: At the bottom of the main screen, you will see a set of buttons for modifying this header information (Default Header, Game Info, Hints, and Sounds). AdventureMaker supplies you with default header material that you probably don't want to use. Be sure to remember to modify it to fit the needs of your own creation. However, if you have completely garbled the job and want to start over, you can click the "Default Header" button, which wipes out your changes and loads in the original default header. It is particularly important that you fill in the "Game Info" record if nothing else, since this sets the title and opening display of your adventure. The Hints dialog is self explanatory, but you may have difficulty with the Sounds dialog. To fill this in, you will need a copy of Inside Macintosh. The numbers are the frequency counts for notes and the note's duration. "Length" tells Adventure! how many notes are in a sound. "Pause" indicates how long of a separator to put between notes. To hear your sounds, click the "Play Snds" buttons down in the lower left corner. A set of Sounds are included in the Default Header, so you don't need to fool with this if you don't want to. After you have finished writing your Header, save it to disk as a Header File. And before you crunch a Block File, be sure to first read in the Header information that you saved. Building a Crunch File: There are two ways to create a Crunch File. First, if you have been working with a single large Block File, you can convert it to a Crunch File very quickly using the Build button. You will be asked for an input Block File and for the name of an output Crunch File. The rest of the compression process will be done automatically. Alternatively, if you have been keeping all of your blocks in separate single-block files, then you must read them in and then write them out to the Crunch File one by one. Use the "Create New Crunch" button to begin with, then click the "Add Crunch" button for subsequent blocks. Remember that the block numbering in the Crunch File must be sequential. Whatever header information is in memory when you create a Crunch File or when you add to a Crunch File is written to the file. If you don't want this to happen (you are appending a block to an existing Crunch File and you don't want the header changed) then un-check the "Write Header" check box. A header will always be written when you first create a Crunch File; un-checking this box only works for when you are adding blocks to an existing file. Revising Your Work: You will _always_ find errors, inconsistencies, poor prose, etc. the first time through an adventure. So it is very important that you be able to revise your blocks easily. Suppose you want to make changes in Block 3 of your adventure. If you have saved your blocks in one large Block File, then type a '3' in the Block Number box, click the Read Block button and select your Block File in the subsequent file dialog. Block 3 will be read from this file into memory. Alternatively, if you have kept separate single-block files, type a '1' in the number box, click the Read Block button and then again select the appropriate file from the file dialog. After you make whatever changes and modifications you wish to the block, you will need to save it again. Type a '3' in the Block Number box, click the 'Add Block' button and save the block directly to your large combined BlockFile as block#3 (an Alert will ask you if you really do want to overwrite an existing block of that file). Or you can save the block as block#1 to its own single-block file. You cannot, however, write the block back to an existing Crunch File as block#3. The reason for this is that the block will have changed size, given any modification at all, so it will no longer fit in its original space in the Crunch File. Crunch Files can be added to on the end, but they must be built anew if an existing block is modified. Option Key Reads and Writes: There is a short cut for reading in block data and writing Block and Crunch Files. After you first click the "Read Block" button, the name of your input Block File is kept in memory. If you want to read another block from that file, you can avoid the standard file dialog by holding down the option key when you click "Read". The same short cut works for writing Block Files and Crunch Files. You must always go through the standard file dialog at least once, but again, the file names are kept in memory as designated output Block and/or Crunch Files. Holding down the option key when you click "Add Block" will write the block to your output Block File. Holding down the option key when you click "Add Crunch" will crunch to block to your output Crunch File. BUILDING AN ADVENTURE RoomRecords The simplest possible adventure would be just a set of rooms. Near the bottom of AdventureMaker's main dialog, it says "Which data set in the memory block do you want to work on?" Click the Rooms button. A blank RoomRecord will appear numbered '1'. Give a Title to the room and fill in the description box. When you have finished with the room, be sure to click 'Write Record' or your work will be lost. (The record is written to the block in memory, not to a disk file.) Now go to the 'Records' menu and choose 'New Empty Record'. If you have just written room record #1, AdventureMaker will present you with a new empty record numbered 2. Fill in this record, write it and continue until you have a nice set of rooms. Don't go past 10 however (AdventureMaker won't let you) since only 10 rooms are allowed in a block. To create more than 10 rooms, you will need to save your current block to disk and start on an entirely new one. (Note: Rather than calling "New Empty Record" from the menu, you can just type in '2' in the Room Number box, change the Room Title, clear the old description and type in a new one, then write the new record. As with blocks, room, object and action records must be built sequentially. If you have only 3 rooms, you can't save the fourth room as room#8.) The description of a room can only be 255 characters. It is _very_ easy to run over this. So as a precaution, after you have written a record, read it (click the read record button). Make sure that your whole description actually got written. If it was too long, you will find that part of it has been chopped off at the end. If you would like to see a summary of your adventure so far, go back to the main dialog and click the Summary button. A page will appear listing all of the rooms, objects and actions in the current block. If you want to examine any of these, click directly on the name. The record for that particular room, object or action will instantly appear. (This only works for records that already exist. If you click a blank on the Summary page, nothing will happen.) Now that you have a set of rooms, you can indicate travel between them. In the Exit boxes in each room, indicate to which room travel in that direction will take the player. For example, if 'N' leads to Room 2 then you would put '2' in the Exit box under 'N'. If travel takes the player out of the current Block into a new one, then you would indicate this by putting a "Room##" in the Exit box. A Room## is the new Block number times 10 plus the new Room number. For example if you want to travel to Block 7 Room 3, then the Room## would be 73 (7*10 + 3). The parser assumes any exit number greater than 10 is a Room##. At this point you might want to try your hand at a flag or two. Put '-2' in the ExitFlag box directly underneath an Exit and fill in the Auxiliary text box in that room with something short but interesting like, "You would suffocate if you went in there." When the player tries to go in that direction, he will be prevented from doing so with this response. The player could wander around a long time in your adventure, if you put enough rooms in, but it would soon cease to be interesting. He couldn't do anything except travel. He couldn't examine objects, take them, drop them or do things with them. The next step ,then, is including some objects. In each RoomRecord in AdventureMaker you will see a row of 10 number boxes labeled 'Objects'. Before you can fill in these boxes, you need to create some objects. ObjectRecords Go back to the Main dialog and click Objects. A blank ObjectRecord will appear numbered '1'. Give at least one name to the object and fill in the main description box. If the object is a plural, be sure to click the plural button. Also, if you want the object to have a modifying adjective, fill this in as well. AdventureMaker automatically assigns 5 points to each new object (and to each room). You can change this if you wish by changing the number in the points box. Below the Names boxes and above the Description box, you will see a whole set of empty number boxes. This is the object's information matrix. Columns 1 and 2 contain Get and Show information. If you want the object to be takeable ( the player can take it and put it in inventory), then put a '1' in row 1, column 1 under Get. You will obviously want some objects to be takeable, like treasures, and others not, like houses. If you want the object to show separately when the player enters a room (Adventure! displays the message, "There is a red ball here."), then put a '1' in row 1, column 2 under Show. Row 1, column 3 through column10, is an object's Action List. This is where you will put the action numbers of the actions that can be performed on, with or by the object. At this point, you can't fill this in because you haven't created any actions yet. We'll come back to this later. Rows 2 and 3 of the object information matrix are for flags. There are a great many different flags that you can use to put conditions or restrictions on actions, to kill people, to activate timers, etc. Here's a simple flag you might want to try right off. In row 2, column 1 under Get, put a '1'. Now fill in the first auxiliary text box (below the main description) with a short message, such as "The box burns when you touch it." From now on, until this flag is removed, if the player tries to take this object, this is the response he will get. In row 2, column 2 under Show, put a '2' , then write a short message in the second auxiliary text box, such as "The box is empty". Now, when the player examines the object, the description he will get will be the auxiliary 2 description. For both of the row 2 Get and Show flags, if you put a '1', then the response will be auxiliary 1; if you put a '2', then the response will be auxiliary 2. When you have finished with the object, be sure to click 'Write Record' or your work will be lost. Now go to the 'Records' menu and choose 'New Empty Record'. If you have just written object #1, AdventureMaker will present you with a new empty record numbered 2. Fill in this record, write it and continue until you have a nice set of objects. Don't go past 20 however (AdventureMaker won't let you) since only 20 objects are allowed in a block. When you have finished defining a set of objects, you might want to check your work by clicking the Summary button in the main dialog. Now that you have a set of objects, you can put them in the rooms you created. If you want object#1 to be in room#1, open up the RoomRecord of room#1 and put a '1' in the "Objects i in Room" list. Put the numbers of any other objects that belong in that room in the list as well. When a player enters this room, he will now be able to examine object#1 and any other object you included in the list. And if you marked the object as takeable, then the player will be able to take the object as well. You now have a pretty good adventure. The player can move around, explore rooms, examine objects, take them and drop them. But that's all the player can do. He can't 'read' a book, or 'open' a box, or do anything that's particularly interesting. The time has come to define some Actions. Before you do this however, it will be instructive to actually try playing the adventure you have created so far. First, save your work to disk as a Block File. This is very important, since once the block is crunched, you won't be able to retrieve it. After you have saved the block, crunch it. Exit AdventureMaker, rename the Crunch File "AdventureFile", put it in your System Folder, open up the Adventure! desk accessory and see how it looks. Travel through your different rooms, examine your objects, take some objects and drop them. You really do have a miniature adventure at this point, and I hope you're a little bit proud of yourself. ActionRecords When you return to AdventureMaker, read in the block you have been working on from its Block File. Click the Summary button to get oriented. You may at this point want to print the Summary page - you'll find this a great help as your adventure grows and becomes complex. To print the page, press cmd-shift-4. Now let's create some Actions. Actions tie everything together in Adventure! It is through actions, and the interaction of actions on objects and rooms, that descriptions change, flags are set or removed, timers are activated, exits open or disappear, players die or win. In the main AdventureMaker dialog, click the Actions button. A blank ActionRecord will appear numbered '1'. Give at least one name to the action. This particular action can act on, or be called by, up to three different objects. As a result, you will see that the ActionRecord has three sets of number and text boxes, one set for each calling object. The first number box in each set must contain the number of the object that is calling the action. For example, suppose object 3 is a 'dog'. And suppose the action you are working on, action 1, is 'pet'. You want the player to be able to "pet the dog". To do this, you would put a '3' in the object number box, since object 3, 'dog', calls the action, 'pet'. Later, you must remember to return to the calling ObjectRecord, in this case object 3, and put a '1' in its Action List. This identifies 'pet' (action 1) as an action that can be performed on 'dog'. You now need to supply a response to the action. In text box A1, type in a suitable response, up to 200 characters long. Adventure! will always use the A1 text box response if an action actually takes place. Text box A2 is reserved for 'failed' actions. (When I refer to an action failing or taking place, I mean something very specific. An action will set flags _only_ if it takes place. A failed action will not set flags.) For example, you might have a flag in your 'dog' ObjectRecord restricting 'pet'. Perhaps the player needs to feed the dog first. In this case, if the player tries to "pet the dog", he won't be able to. The action will not take place and Adventure! will display the A2 response. You would therefore want to type in a suitable negative response in the A2 box. If an action will never 'fail', i.e. would never have a restriction on it, you can leave A2 blank. To continue our example, you evidently want the player to be able to feed the dog. 'Feed' is a new action, separate and distinct from 'pet'. Open up a new ActionRecord, action 2. (Be sure to write action 1 first.) Give it the name 'feed' and again put a '3' in the object number box in the first row (since object 3 is again the calling object). In your 'dog' ObjectRecord, add a '2' to the Action List. Now 'dog' calls both 'pet' (action 1) and 'feed' (action 2). Our 'pet'/'feed' example is a good place to begin exploring the power of flags. Everything in Adventure! is driven by flags. And this dynamic takes place primarily through actions. I suggested above that there might be a restriction on "pet the dog". How would we set this restriction? The easiest way is to put a '-1' in row 2 of the ObjectRecord directly under the 'pet' action number in the Action List. A flag of '-1' simply means the action can't be done. Remember that the Action List is row 1, column 3 through column 10. Suppose that you put '1', for action 1 ('pet'), in row 1, column 3. Then to restrict this action, put a '-1' in row 2, column 3, directly under the '1'. I know this sounds a little complicated, but it's not. Give it a try. "Pet the dog" is now restricted and cannot be done. When the player tries to do so, he will get the A2 text box response. How can we remove this restriction? If the player first feeds the dog, he should then be allowed to pet the dog. So 'feeding' the dog should remove the restriction on 'pet'. We do this with the room and object flags in the action record. Open up ActionRecord 2 ('feed') and look at the first row of number boxes. '3' is in the very first box, since this is the object# of the calling object. Ignore the second number box (labeled Aux) for now. There are seven more boxes in the row. The first three number boxes, labeled Room Flags, set room flags; the last four boxes, labeled Object Flags, set object flags. I will refer to these boxes as the 'setflag' boxes from now on. And that's what we want to do here. We want to set the '-1' flag on 'pet the dog' to '0'. In other words, if the player feeds the dog, then the restriction on 'pet' is removed and the player can then pet the dog. In the first object setflag box (labeled 'obj) put the object number of the object that you want to affect ('3' in this case). The flag that we want to change is in row 2, column 3 of this ObjectRecord, so put '2' in the "row" box, '3' in the "col" box. Finally, in the box labeled "#", put a '0'. What this series of numbers says is that the action "feed the dog" will set row 2, column 3 of object 3 to 0. This removes the restriction on "pet the dog". From now on the player will be able to pet the dog as much as he wishes. You might also want an action to open up a new exit to a room. For example, perhaps you had a '-2' flag on the east exit from room 4, with an auxiliary room description of "The dog won't let you pass." You want "feed the dog" to open up this exit. To remove the restriction on the exit, fill in the room setflag boxes in the 'feed' ActionRecord. Put the room# ('4') in the box labeled "rm", put a '3' in the "col" box ('east' is column 3 in a room's exit list), and put '0' in the box labeled '#'. This sets the east exitflag in room 4 to '0'. The player can now travel east from that room. In many cases, you will want an action to set more than one object flag and/or room flag. To set more flags, move down to the second row of setflag boxes in the ActionRecord. Again, in the first box, fill in the number of the calling object (you must always do this or the parser will simply skip that row of setflags). Fill in the room and object setflag boxes as you wish. You do _not_ want to put any text in the A1/A2 text boxes in this second set of setflags. The parser will use the text you already supplied above. You can now move down to the third row of setflags, heading it with the same object# if you wish. Or you can use this third row to respond to an entirely new object. Or you can leave it blank. If this is a new object, you must again supply some text in the A1/A2 response boxes. For example, suppose you want to be able to "feed the bears" in your adventure. If 'bears' is object 4, then you would head the setflag row with '4'. You would fill in the A1/A2 text boxes with appropriate responses. You would fill in the setflag boxes giving the results of feeding the bears. And in the "bears" ObjectRecord, you would put '2' (for action 2, 'feed') in the Action List. The single most important thing to remember in writing ActionRecords is to make sure that all of your cross-references are correct. In the ActionRecords, you must be sure to fill in the numbers of the calling objects. In the ObjectRecords, you must be sure to put the numbers of the called actions in the Action List. Also, make sure that an object doesn't call two different actions with the same name. Since six action names are allowed, this does happen sometimes. The results are never what you want. As you can see, actions are the driving force in Adventure! Actions set flags. And it is flags that give all the interest, the challenge and the frustration to a good adventure game. So far, I have only mentioned a couple of different flags. Adventure! recognizes a large number of flags, all having different consequences. But before continuing, you should fill in a few action records, save your work as a Crunch File and try playing the adventure you have developed so far. See if your actions work. Try setting a few of the simple flags already discussed. If you feel comfortable with your results, then read on. If not, don't venture further until you've gotten the basics under your belt. ADVANCED ACTIONS So far we have discussed the basic interplay of actions on objects and rooms. Most ActionRecords that you write will behave in the way just discussed. However, there are a number of "special" actions that are written differently and behave differently. We will look at those here. Special actions in Adventure! include: 1] the object as a verb 2] prepositional phrases 3] 'go' as an action 4] 'take' or 'drop' as actions 5] the Time function 6] the Moss function The Object as a Verb: Sometimes, you'll want to be able to respond to single-word sentences such as "jump" or "dig" or "search". The parser will interpret these commands as objects (even though you and I know they are verbs). So in rooms where such commands are likely, you should include objects with the relevant verb as one of its names. For example, you might have an object with the name "swim". In order to provide a response when the player types "swim", the object 'swim' must call an action, since only actions can give responses and set flags. The way to deal with this is to name the called action "nil". In other words, the parser interprets the player's instruction as "nil swim". It will look through the Action List of the object "swim" until it encounters an action named "nil" and will then carry out the appropriate response given in the "nil" ActionRecord. You might think this is a waste of object space, but you can cleverly do some doubling up here. No player is going to "examine swim", or at least it's unlikely. So "swim" can be but one of the six possible names for, say, "lake". Then one of the actions called by "lake" (aka "swim") would be the action "nil". Thus, in one ObjectRecord, you can combined two separate objects: "lake" and "swim". Prepositional Phrases: Suppose you want the player to be able to "throw the axe over the cliff". This is not your standard verb/noun sentence. In fact, it has two nouns, 'axe' and 'cliff', separated by the preposition 'over'. When the parser in Adventure! finds a prepositional phrase like this, it will interpret it as follows: The first noun in the sentence, 'axe' is considered to be the primary object, i.e. it is the object that calls the action 'throw'. 'Throw' must therefore be an action in 'axe"s Action List. The noun following the preposition is considered to be an 'auxiliary noun', so in this case, the auxiliary noun is 'cliff'. The parser will then look at the ActionRecord for 'throw', will look for the row of setflags starting with the object number of 'axe' and will then check to see if there is a number in the Aux box of that row. (The Aux box is the the second box in a setflag row.) That number must be the object## for 'cliff'. An object## is the original block number of the object times 20 plus the original object number of the object. For example, suppose 'cliff' is object number 5 in block 7. The the object## for cliff would be 145 ( = 20*7 + 5). The parser will now examine all of the objects in the room and in the player's inventory to see if one of them has an object## of 145. If one of them does, then the action will take place. If the parser can't find object## 145, then the action will fail. In a nutshell then, if you want an action to depend on a prepositional phrase, put the object## of the auxiliary object in the Aux box. That's all there is to it. By the way, Adventure! recognizes a preposition _only_ if it is in the Preposition List. This is a list in the header information of a Crunch File. You can modify this list if you need to. Click the "Prep List" button in the Game Info dialog. 'Go' is an Action: This is a very powerful action function and you will want to use it frequently. Normally, when a player travels from room to room, the parser recognizes the player's travel instruction as being just that and goes straight to a 'travel' procedure. No flags are set, and the only response a player gets is either the new room description, or a "you can't go there" type response. However, sometimes you want the player's travel instruction to set flags and/or give a unique response. To do this, you need to turn the normal travel instruction into a true action. The way to do this is to have the travel instruction call an action. But only objects can call actions, so you have to turn the travel instruction into an object. When the parser looks at the ExitFlags in a room, if it finds an ExitFlag between 1 and 20, it will automatically assume that this is an object calling a 'go' action. It will then look in the room's object list for an object _named_ that particular ExitFlag number. For example, if the ExitFlag is '9', the parser will look for an object named '9'. Note that any object could have '9' as one of its names -the parser doesn't care- but to minimize confusion for your own sake, I suggest that you give object#9 the name '9'. Once the parser has found the appropriate object, it will search the object's Action List for an action named 'go'. It will then execute the instructions in the 'go' ActionRecord, just as it would any called action. If the action is non-restricted, the parser will set flags and then display the action's A1 text followed by More. It will then complete the original travel instruction given by the player. If the action is restricted (e.g. there is a flag on it in the ObjectRecord of the calling object) then the parser will display the action's A2 text, will not set flags, and will not complete the player's travel instruction. If you leave the A1/A2 textboxes blank, the parser will set flags (or not) invisibly, using standard travel responses. This does get a bit confusing, so here is an example. Suppose you put '3' in the ExitFlag box. Then of the six possible names for object#3, one would have to be '3'. When you put '3' in the ExitFlag box, you are basically telling Adventure! to "go 3". The parser looks for the object named '3', then looks at 3's Action List to find an action named 'go'. It then does whatever 'go' tells it to, i.e. it sets flags, displays text, kills people or whatever, and then travels to the new room. Remember, the action 'go' is subject to all the flags that any action would be, so if you have restrictions on the action, then neither will the action will take place, nor will Adventure! complete the original travel instruction. A final note: this function is highly error prone. Not by the parser, but by you. Make sure that the object is in the room, make sure that one of the object's names is the object# itself, and make sure that one of the actions that the object calls has the name of 'go'. 'Take' and 'Drop' as Actions: The verbs "take" and "drop" are built in to Adventure! When the parser encounters these, it goes straight to the Inventory procedure. If you want 'take' or 'drop' to behave like true actions, you need to tell the parser that this is the case. It's very easy to do so. Just put '-1' in an object's Get Box (row 1, column 1) if you want 'take' to be an action. The parser will then search the object's Action List for an action named 'take'. It the action is non-restricted, it will set flags, give the A1 response if provided, and then complete the original inventory instruction. If 'take' is restricted, then the A2 response will be given, no flags will be set, and the inventory instruction will not carried out. In both cases, if A1/A2 are left blank, standard Inventory responses will be used. If you want 'drop' to be an action, put '-2' in the object's Get Box and be sure to include 'drop' as one of the actions in the object's Action LIst. Finally, if you want both 'take' and 'drop' to be actions, put '-3' in the object's Get Box. In this case, both 'take' and 'drop' should be in the object's Action List as two separate actions. The Time Function: Adventure! has two different timer functions: a short one and a long one. The short one is Time. It is called with an ObjectRecord flag of '1' or '2'. The action that has been flagged in this way becomes a Time record and is treated by the parser in a special way. The parser sets the flags indicated in the ActionRecord, gives the action's A1 response and starts a timer ticking. The flags set by the Time record are set _only_ for the duration of the timer. When the timer expires, the room and object flags set by the Time record revert to their original values and the action's A2 text is displayed indicating the end of the Time function. You can also set Exits (as opposed to ExitFlags) with the Time record, but these will not revert when the timer expires. The change is permanent. This is an unfortunate exception, but was necessary due to size limitations. The timer lasts only a few moves. (You set the number of moves, the TimeCount, in the Game Info header dialog.) Note that each character typed by the player is counted as a 'move', so 'n' is 1 move, while 'go north' is 8 moves. The timer always expires if the player crosses a block boundary or saves a game. Do not allow the player to do an action while the timer is activated that will set any of the flags affected by the Time record. Otherwise, when the timer expires, the flags will revert to the values saved by the time function when it began. This would then wipe out your player's actions. A number of flags work off of the Time function. (See the Flag list below.) You can specify that an action can or cannot take place if or if not Time. An example of a flagged Time function is the apples in "The Temple of Goth". Eating the apples starts a Time function. The player can enter the hole in the base of the tree only while Time is in effect. The Moss Function: The long term timer function in Adventure! is Moss. Moss can invoke multiple interruptions, can survive a Save/Restore and can cross block boundaries. It differs from the simple Time function in that it cannot restore flags to their original setting before Moss started. Careful here! Moss records are very different from standard ActionRecords. They are never called directly by an object, but rather by an action. Here's the way it works: An object calling an action has a MossFlag set (row 3 = -8). The parser executes the action, but while it's doing that, it looks at the called action to see if it has an Aux number between 1 and 15. If it does, then the parser considers the action record with that number to be a MossRecord. It reads the data of a MossRecord as follows: Names: These are ignored. But remember, you can't leave an action's name list completely blank (the record would not be written to the Crunch File if it were nameless). You must fill in at least one name. A good name in this case is 'moss'. Then you know at a glance it's a MossRecord. Obj#'s: These are ignored. For your own reference you may want to include here the numbers of the calling objects or actions. Aux#'s: Only the first is used. This must give the number of Moss interruptions (which must equal the number of TimeChecks and the number of MossText messages). It is very important that you set this number. If you leave it blank, the Moss sequence will never take place. Room and Object SetFlags: In the first row only, starting with the Rm box, fill in up to six TimeChecks. These are integers that indicate after how many moves a Moss interruption will occur. You should include as many TimeChecks as the number indicated in the Aux box. TextBoxes: Working _vertically_ (i.e. A1,A1,A1,then A2,A2,A2) fill in the MossText messages that will be displayed for each Moss interruption. You should include as many MossText messages as TimeChecks. Remember, the number of interruptions is indicated in the Aux box. If you want something interesting to happen at the end of a Moss sequence, this must be indicated by the calling object when Moss is first invoked. You invoke Moss by putting a '-8' in row 3 under the relevant action. If you want a player to die if he doesn't succeed in "curing" Moss, then put a '-9' in row 2. If you want the player to be transported, put a Room## in row 2. As with Time, there is a set of flags contingent on Moss. See the Flag list below. The most important of these is '-7' which will cure Moss (cancel the timing function) whenever it is encountered. There are a number of Moss timer functions in "The Temple of Goth". The original Moss function is, of course, the moss disease in Block 1. Other examples of Moss are the creature in the fog , the processions of monks, and the destruction of the Temple at the end of the game. ALLOWED TEXT SIZES I've already mentioned some of these, but here's a list for reference: Objects: names 10 characters adjective 10 characters main description 255 characters aux1 80 characters aux2 80 characters Rooms: name 20 characters main description 255 characters auxiliary 80 characters Actions: names 10 characters A1 200 characters A2 200 characters Other: prepositions 10 characters Opening Text 255 characters Hints 255 characters The parser will always truncate a player's verbs, adjectives and nouns to 10 characters each. This means you can too in your name lists. For example, if you want use the action "concentrate", this will get truncated in the action record to "concentrat". But that's all right. When the player types "concentrate", his instruction will also be truncated and will thus match up with your action name. Don't allow _any_ name that will be displayed to be truncated, however. For example, if you have a "Fiddlefaddle" object that can be taken and put in inventory, when the Fiddlefaddle is dropped, it will appear in the room as a "FiddleFadd". Oops. Adventure! always uses the first name in an object's name list as the display name. So be careful to make this a good descriptive name, 10 or fewer characters long. FLAGS Adventure! is driven by flags. They are numerous, obscure and hard to remember. In this section , I provide brief descriptions of all of the flags for the different record sets. But rather than my trying to tell you, in detail, what each of these does, the best way to learn about them is by example and by trial and error. Open up the example BlockFile supplied with AdventureMaker. (This happens to be Block 1 of the "Temple of Goth". If you haven't solved "The Temple of Goth" yet, be forewarned that this BlockFile will reveal some solutions to puzzles in the game.) Study how the flags are used there. And try using some of these flags in your own adventure. You'll soon get a feel for them. In what follows, any number referred to with "##" is a combination giving both block number and room or object number. Calculate these as follows: Room## = (Block#)*(10) + Room# Object## = (Block#)*(20) + Object# ROOM RECORDS Room Exits: 0 < num <= 10 go to room# 10 < num <= 110 go to room## (new block) Room ExitFlags: 20 < num <= 220 need object ## 0 < num <= 20 'go' is an action called by object 'num' num = -1 just can't go num = -2 can't go with auxiliary description num = -3 can't go if have items in inventory num = -4 drop everything then go num = -7 cure Moss then go -220 <= num < -20 can't have the object## OBJECT RECORDS Get/Show Flags (Columns 1 and 2): Get Show Row 1 0 can't get 0 don't show 1 can get 1 do show -1 take is an action -2 drop is an action -3 both take and drop are actions Row 2 0 main description 0 main description 1 aux 1 description 1 aux 1 description 2 aux 2 description 2 aux 2 description Row 3 not used drop other object## The Row 3, Column 3 flag, "drop other object##" is very useful if you have two objects that you want to travel together in inventory. For example, if you want water to travel only in a bucket, then when the player drops the bucket, the water should get dropped as well. Indicate this by putting the object## of water in Row 3, Column 3 of the bucket's information matrix. The Action List (Row 1, Column 3 to Column 10): The Action List holds the action numbers of the actions that can be performed on or by the object. If you want to allow a one-word verb command, eg 'jump', then the action called should have the name 'nil'. If you want a travel instruction to set flags and/or give a text response, then the action called must have the name 'go' and the calling object must have its own object number as one of its names. If there are no restrictions on the action, the travel instruction will then be carried as usual. If you want 'take' to set flags and/or give a text response, then the Get Flag of the ObjectRecord must be '-1' and the action called should have the name 'take'. For 'drop', the Get Flag must be '-2' and the action name must be 'drop'. If the Get Flag is '-3', then the parser will consider both 'take' and 'drop' to be true actions. If there are no restrictions on the actions, both 'take' and 'drop' will also carry out their normal inventory functions. One thing to remember is that an object's Action List is permanent. You can change action numbers with action setflags, but these changes won't 'travel' across block boundaries or through a save/restore. When a new block is read in from disk, the Action List will revert to its original form. An object's Row 2 and Row 3 flags, on the other hand, will travel nicely, as will any Get/Show flag. Only the Action List itself is permanent. Row 2 and Row 3 Flags (Column 3 to Column 10): There is quite a bit of duplication here (you'll wish there were more), but in general Row 2 flags govern room interactions and Row 3 flags govern object interactions. It is very important to remember that Row 3 flags are checked _before_ Row 2 flags. If there is a Row 3 restriction (say, -1) then the Row 2 request will not be carried out (transport, for example). On the other hand, if there is a Row 2 restriction ( -1 perhaps), then a Row 3 request (clear moss, say) _will_ be carried out, because this will happen before the Row 2 flag is examined by the parser. Row 2 Flags: num = 111 random travel 10 < num <= 110 travel to new Room## num = 6 remove the object num = 5 drop the object num = 4 take the auxiliary object num = 3 take the object num = 2 start timer /no sound num = 1 start timer /with sound num = -1 just can't do num = -7 clear moss num = -9 you're dead -110 <= num < -10 must be in Room## for action to take place. Notes: The "remove object" flag makes an object in inventory disappear. It is removed from inventory and from the game. The "drop object" flag, on the otherhand, literally drops the object in the room. The player can retrieve the object later. The "take auxiliary object" flag works with a prepositional phrase. It enables you to "fill the bucket with water". "Water" is an auxiliary object indicated in the "fill" action record. If the action "fill" is flagged with 4 in the "bucket" object record, then "water" will be put in inventory. Row 3 Flags: 20 < num <= 220 need the object## for action to take place. num = 6 remove the object (it disappears) num = 5 drop the object num = 4 take the auxiliary object num = 3 take the object num = 2 start timer /no sound num = 1 start timer /with sound num = -1 just can't do num = -2 clear timer num = -3 can't do if not Time num = -4 can't do if Time num = -5 can't do if not Moss num = -6 can't do if Moss num = -7 clear Moss num = -8 Moss -220 <= num < -20 can't do if have the object## Special Combinations: If an action is flagged with '-9' (death) in Row 2 and a Row 3 flag for that action is set, then player will die if the action _can't_ be done, but not otherwise. For example, the Row 3 flag might be an object## indicating that a certain object is needed, a gas mask let's say, in order for the flagged action to take place. If the player doesn't have the gas mask and he tries to do that action, he will die. If he does have the gas mask, he won't die, and the action will take place as requested If a Row 2 'death' or 'travel' flag is set when Moss is invoked then the flagged result (death or travel) will take place at the last TimeCheck of the Moss sequence, and only if the Moss has not been 'cured' by then. By the way, try not to kill off your players with too much abandon. A little danger adds spice, but senseless, illogical, gratuitous deaths get very frustrating for the player and add nothing to an adventure. ACTION RECORDS An action _must_ have at least one name, otherwise the record will not be written. Special Action Names: 'nil' - allows the calling object to be a stand-alone verb. 'take'/ 'drop' - allows standard inventory instructions to behave as true actions. (This works only if flagged in an object's Get Box ). 'go' - enables travel instructions to behave as true actions. (If the 'N' exit is flagged with 12, then the parser interprets this as 'go 12'. It looks for an object named '12', then searches that object's action list for an action named 'go'.) SetFlags: Each action can be called by up to three different objects. For each calling object, there is a row of setflag boxes, headed by the number of the calling object: Calling Room setflags Object setflags obj# aux Rm col set# Obj row col set# ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ Aux Num: 20 < aux <= 220 Aux gives the object## for use in a prepositional phrase. For 'put note in box', then aux would be the object## of box. 0 < aux <= 15 If a MossFlag is set in the calling object then aux must contain the number of the action that is serving as the MossRecord. Room SetFlags: If the col# is negative, then Exits are set. If the col# is positive then ExitFlags are set: col < 0 sets Exits in Rm to set# col > 0 sets ExitFlags in Rm to set# For example, if the room setflags are [3, 4, -2] then this will set the West Exitflag (col 4) to '-2' in Room 3. From now on, when the player tries to go west in that room, he will get the auxiliary text in that room record. If the room setflags are [7, -2, 43], then this will set the South Exit (col 2) in Room 7 to '43'. From now on, when the player travels south out of Room 7, he will end up in Block 4, Room 3. Object SetFlags: Changes the values of the obj's information matrix to the set#. For example, if the object setflags are [19, 2, 2, 1] then this will set Row 2, Column 2 of object 19 to '1'. From now on, when the player 'examines' object 19, he will get the description in object 19's aux1 textbox. Text Boxes: A1 = text used if action is doable. A2 = text used if action can't be done. Note that actions _cannot_ set the flags of objects or rooms in other blocks! This is not a problem for stationary objects, but can be a bother for traveling objects (those in inventory). The action parser will always check to see that an object originates in a block before it will go ahead and set any flags. The reason for this is that when the player crosses a block boundary, all non-resident actions and objects get renumbered. Only a Supreme Power, or a much larger Adventure! desk accessory, could keep track of what action was setting what object after such a renumbering. There is one exception to this. If you specify with an object flag that an action can only take place in a specific room, then the action parser will go ahead and set flags, even though the object is no longer in its originating block. It is up to you to make sure that you know just what flags are being set in this case. Special Action Records: Time Records: If a TimeFlag is set in the calling object, then Room and Object SetFlags will be set _only_ for the duration of the timer. Values then revert to the original settings when the timer expires. (An exception is if Exits are changed - the change is permanent.) TextBox A1 gives the text for timer activation. TextBox A2 gives the text for end of timer. The timer lasts only a few moves. (You set the number of moves in the Game Info header dialog.) The timer always expires if the player crosses a block boundary or saves a game. Moss Records: "Moss" is a long term timer function. It can invoke multiple interruptions, can survive a Save/Restore and can cross block boundaries. It differs from the simple "Time" function in that it cannot restore flags to their original setting before Moss started. If an object calling an action has a MossFlag set, then when the parser executes the action it looks at the called action to see if it has an Aux number between 0 and 15. If it does, then the parser considers the action record with that number to be a MossRecord. It reads the data of a MossRecord as follows: -Names: These are ignored, but you need to put something there or the record will be skipped. A good practice is to name a MossRecord "moss". -Obj#'s: These are ignored. For your own reference you may want to include here the numbers of the calling objects or actions. -Aux's: Only the first Aux number in the first row is used. It is very important that you fill this in. It must give the number of Moss interruptions (which must equal the number of TimeChecks and the number of text responses). If you leave this blank, the parser will assume there are zero moss interruptions and nothing will happen. -Room and Object SetFlags: In the first row only, starting with the Rm box, fill in up to six TimeChecks. These are integers that indicate after how many moves a Moss interruption will occur. The number of TimeChecks must equal the number you put in the Aux box. -TextBoxes: Working _vertically_ (i.e. A1,A1,A1,then A2,A2,A2) fill in the MossText messages that will be displayed for each Moss interruption. The number of messages should be the same as the number of TimeChecks and the number in the Aux box. In the calling ObjectRecord, if a Row 2 'death' or 'travel' flag is set when Moss is invoked then the flagged result (death or travel) will take place at the last TimeCheck of the Moss sequence if the Moss has not been 'cured' by then. YOU'RE ON YOUR OWN NOW. WELL SORT OF. I'm sure I've forgotten to mention many things. But I do believe that once you get started you will get a feel for how the flags and interactions work and will only need to look at these instructions for reference. By the way, the Flag list, which is impossible to remember, is included in the "About..." box under the Apple Menu in AdventureMaker. If you have questions, and I'm sure you will, feel free to ask. I can be contacted on CompuServe, Genie and MacNet, or you can write to the address given at the beginning of these instructions. You don't need to pay the registration fee just to get help. I really do want to see some good adventures created and will do what I can to get you started. If you succeed if writing a super adventure and wish to distribute it publically, I do ask that you pay the $30 registration fee before you do so. Among other things, this will enable me to keep track of who is publishing what with my program. Also, registered AdventureMaker users will be kept informed of revisions and updates to both Adventure! and AdventureMaker. Patricia Smith Epiboly SoftWare CIS: 70655,425 325 E. 79th Street, Apt. 13d MacNet: SmithPB New York, NY 10021 Genie: P-Smith AdventureMaker, Version 1.0, Copyright 1988, portions Think Technologies.